In recent times there has been a significant increase in the number of battery-driven handheld devices. Unfortunately, the battery technology has not advanced as fast as the technology of the power-hungry hardware that runs these devices. Thus, the batteries of portable and mobile devices tend to discharge relatively quickly and, hence, power management is a key consideration in the design of such devices. Low power consumption is a major system-level design issue that typically cannot be added to an existing system later on. Rather, it is accounted for in a system's hardware and software by using energy-saving components and implementing dynamic power-management techniques.
The processors used in these devices thus support many operational modes that have different performance and power consumption characteristics. One such low-power state can be a SLEEP state wherein the clocks of the system are stopped. In this state the system is completely idle and the context of the system is retained, including the contents of the CPU registers, caches, peripheral registers and RAM. Implementing dynamic power-management techniques involve entering and exiting these low-power modes whenever feasible.
The memory used in the computer system is normally a synchronous dynamic random access memory (SDRAM) since it is faster than extended data out random access memory (EDO DRAM), fast page mode (FPM) DRAM, or another type of dynamic random access memory (DRAM). Static random access memory (SRAM) is faster and more reliable than DRAM but unfortunately is also much more expensive than DRAM.
All these types of DRAM need to be periodically refreshed in order to maintain the data values stored in them. Some types of DRAM, including SDRAM, are able to execute self-refresh cycles. In a self-refresh cycle, the DRAM uses an internal clocking to refresh itself, and no external clocks are required. Once the DRAM is placed into the self-refresh mode using a self-refresh command, the system clock may be turned off without affecting the contents. However, during the period when the DRAM is in self-refresh mode no accesses can be made to it.
FIG. 1 illustrates the problem associated with entry and exit from the SLEEP mode due to the restriction that no accesses to the SDRAM 3 can be made when it is in self-refresh mode. Before entry into the SLEEP mode, the SDRAM 3 is put in the self-refresh mode. But the entire code itself resides in the SDRAM 3. Thus, once the code 4 that puts the SDRAM 3 in self-refresh gets executed, the subsequent code 5 cannot be executed since no SDRAM 3 accesses are permitted in self-refresh mode.
FIG. 2 illustrates the solution to this problem as proposed by U.S. Pat. No. 6,571,333 by making use of a second (non-volatile) memory 10. This second memory 10 stores the code instead of the SDRAM 9 to put the SDRAM 9 into self-refresh and then the chip 6 in SLEEP mode. Thus, the use of this second memory 10 avoids accesses to the primary SDRAM 9 after putting it in self-refresh.
In this existing solution the SLEEP entry and exit code (called System Management Software or SMM) is placed in the second memory 10 and the control to SMM is transferred through a change in address mapping (PAM register) and a System Management Interrupt (SMI). Moreover, since the code from a second memory 10 puts the SDRAM 9 in self-refresh, cache 8 needs to be flushed before enabling SDRAM 9 self-refresh to avoid write-backs to SDRAM 9 due to cache 8 eviction. This is done in spite of the fact that cache 8 contents are preserved during the SLEEP (defined as S1 in the solution) mode. All these activities have a clear overhead associated with them.
In the proposed solution, the aforesaid problems relating to the entry and exit from SLEEP state are being dealt with. An embodiment of the invention uses cache pre-fetching of a certain set of instructions and the associated data, which are to be definitely executed thereby avoiding any accesses to the SDRAM while it is in self-refresh. The solution obviates the need of a second memory and the need of cache flushing for SLEEP entry and exit purpose. The code is built-in as a small library into the operating system and SLEEP entry and exit is reduced to a simple function call to the appropriate routine.